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METHOD FOR ACTIVATING MULTIMEDIA 
BROADCAST/MULTICAST SERVICE 

Field of the Technology Invention 

The present invention relates to service activation technology, and in particular, 
5 to a method for realizing the Multimedia Broadcast/Multicast Service (MBMS) 
activation. 

Background of the Invention 

Development of 3 rd Generation Mobile Communication Technology makes it 
possible to provide services with a higher data transfer speed than 2 nd Generation 

10 Mobile Communication does, and further support many new services, such as video 
telephone, downloading pictures and high speed Internet browsing, etc. Some services 
thereof have the following common features: it is possible to send corresponding data 
simultaneously to all subscribers who customized the service in radio network, for 
instance, sending weather forecast, short newsreel and sports performance collection 

15 etc. Based on the feature that data of these services can be sent at the same time, 3 rd 
Generation Mobile Communication introduces the concept of multicast/broadcast. 

As shown in Figure 1 , for a middle node, for example, node 1 0, no matter how 
many downstream nodes expect to receive data, its upstream node always transmits 
one copy of the data to the middle node; after receiving the data, the middle node 

20 replicates the data into several copies according to the number of the downstream 
nodes that expect to receive the data and distributes the data to the each downstream 
node, for example, the downstream nodes of node 10 expecting to receive the data 
containing node 101 and node 102, so node 10 duplicates two copies of the received 
data. In this way, each branch of MBMS transmission tree has only one copy of data 

25 to transmit, sharing one copy of transmission source, and so does the data 
transmission of the root node and its downstream nodes. The difference between 
broadcast service and multicast service is: multicast service transmits corresponding 
information only to the subscribers who subscribed to particular information, while 
broadcast service transmits information to all the subscribers in radio network. It can 

30 be seen from the above description that providing the same information to a great 
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number of subscribers through MBMS bearer service can save network sources 
greatly. 

Figure 2 illustrates the radio network architecture which supports MBMS bearer 
service, wherein the network entities include a Broadcast-Multicast Service Center 
5 (BM-SC) 201 which supports multicast/broadcast service, a Gateway GPRS Support 
Node (GGSN) 202, a Serving GPRS Support Node (SGSN) 203, a Universal 
Terrestrial Radio Access Network (UTRAN) 204 of Universal Mobile 
Telecommunication System (UMTS), a GSM/EDGE Radio Access Network 
(GERAN) 205 in Global System of Mobile communication (GSM) and User 

10 Equipment (UEs) 206 and 207. As shown in Figure 2, in the conventional 3 rd 
Generation Partnership Project (3 GPP) frame, BM-SC 201 is connected to GGSN 202 
through a Gmb interface or a Gi interface, where one BM-SC 201 can be connected to 
several GGSNs as GGSN 202. GGSN 202 is connected to SGSN 203 through a 
Gn/Gp interface, where one GGSN 202 can be connected to several SGSNs as SGSNs 

15 203. SGSN 203 can be connected to UTRAN 204 through an Iu interface and 
UTRAN 204 is connected to UE 206 through a Uu interface. SGSN 203 can also be 
connected to GERAN 205 through an Iu/Gb interface, and GERAN 205 is connected 
to UE 207 through a Urn interface. The BM-SC can be a BSC/RNC. 

Combining Figure 1 and Figure 2, BM-SC 201 is equivalent to a root node of a 
20 tree structure. The downstream node of BM-SC 201 is GGSN 202. The downstream 
node of GGSN 202 is SGSN 203. The downstream nodes of SGSN 203 are UEs 206 
and 207. Of course, there can be more than one GGSNs and SGSNs. It is obvious that 
the data distribution of MBMS bearer service is implemented through a tree structure, 
which commonly implemented through multiple BSC/RNCs, SGSNs and GGSNs. 
25 Furthermore, some bearer resources are needed to be shared between subscribers who 
use a same MBMS bearer service. Therefore, a uniform QoS is created at each branch 
of the MBMS distribution tree. For above characteristics, when a new branch of the 
MBMS distribution tree is created, the QoS of the whole distribution tree should not 
be affected by this new branch. Accordingly, a QoS negotiation should not be 
30 implemented in UMTS network. If the network cannot accept QoS requirements of 
particular branches, as a result, these branches cannot be created. For instance, when 
the MBMS bearer capabilities of a particular UE are less than the Required MBMS 
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Bearer Capabilities of a MBMS bear service, the UE will be rejected to use this 
MBMS bearer service by the network. 

In current specification, the BM-SC can transmit the Required MBMS Bearer 
Capabilities corresponding to an MBMS bearer service through an MBMS 
5 Registration Procedure to a GGSN and a SGSN. The Required MBMS Bearer 
Capabilities may identify the minimum bearer capabilities requested by the UE when 
the UE receives the MBMS bearer service, that is, the maximum QoS ability that the 
MBMS bearer service possibly uses. When the UE joins the MBMS bearer service 
through an MBMS bearer service activation procedure, the network needs to verify 
10 whether the MBMS bearer capabilities of the UE satisfy the Required MBMS Bearer 
Capabilities. 

The MBMS Bearer Context is used to store the Required MBMS Bearer 
Capabilities, which contain all the description information defining an MBMS bearer 
service and are created at all nodes that bear the MBMS data. As shown in Table 1, 

15 the MBMS Bearer Context includes an IP multicast address, an Access Point Name 
(APN), a Temporary Mobile Group Identification (TMGI), a State, a Required 
MBMS Bearer Capabilities, a QoS, an MBMS bearer service Area, a List of 
downstream nodes, a Number of UEs and so on. The IP multicast address identifies an 
MBMS bearer service described by this MBMS Bearer Context. The APN is an 

20 access point name on which this EP multicast address is defined. The TMGI is a 
temporary mobile group identity allocated to the MBMS bearer service. The State is 
the state of bearer plane resources, i.e., "Standby" or "Active" state. The Required 
MBMS Bearer Capabilities refer to the minimum bearer capabilities the UE needs to 
support. The QoS means Quality of Service required by the MBMS bearer service. 

25 The MBMS bearer service Area is the area over which the MBMS bearer service has 
to be distributed. The List of downstream nodes refers to the List of downstream 
nodes which requested the MBMS bearer service and to which notifications and 
MBMS data have to be distributed. The number of UEs means the number of UEs 
hosted by the node which joined the MBMS bearer service. 
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Parameter 


Description 


RAN 


SGSN 


GGSN 


BM- 

SC 


IP multicast 
address 


IP multicast address identifying the MBMS 
bearer described by this MBMS Bearer 
Context. 


X 


X 


x 


X 


APN 


Access Point Name on which this IP multicast 
address is defined. 


X 


X 


X 


Undet 
ermin 
ed 


TMGI 


Temporary Mobile Group Identity allocated 
to the MBMS bearer service. 


X 


X 


X 


X 


State 


State of bearer nlane resources Cstandbv' or 
'active') 


Undet 
ermin 
ed 


x 


x 


x 


Required MBMS 

Bearer 

Capabilities 


Minimum bearer capabilities the UE needs to 
support 




X 


X 


X 


QoS 


Quality of Service required for the MBMS 
bearer service. 


X 


X 


X 


X 


MBMS bearer 
service Area 


Area over which the 1VTRA/TS hearer service 
has to be distributed. 


X 


x 


x 


x 


List of 

downstream 

nodes 


List of downstream nodes that have requested 
the MBMS bearer service and to which 
notifications and MBMS data have to be 
forwarded. 




X 


X 


X 


Number of UEs 


Number of UEs hosted by the node that have 
joined the multicast MBMS bearer service. 


Undet 
ermin 
ed 


X 


X 


Undet 
ermin 
ed 



Table 1 



During the MBMS bearer service activation procedure, the subscriber is 
registered in the network to be enabled to receive data from a specific multicast 
MBMS bearer service. The activation is a signaling procedure between the UE and 
5 the network, which establishes an MBMS UE Context at UE, SGSN, GGSN and 
BSC/RNC for each activated multicast MBMS bearer service. The establishment of 
MBMS UE Context is similar as the establishment of general PDP context. The 
MBMS UE Context contains particular information of the particular MBMS bearer 
service which the UE joined. When the UE joins an MBMS bearer service, the 
10 MBMS UE Context is created at the UE, SGSN and GGSN. The MBMS UE Context 
is stored as part of the MM Context of the UE and is stored in the GGSN solely. 
There is one MBMS UE Context for each MBMS bearer service which the UE joined. 
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As shown in Table 2, the MBMS UE Context includes an IP multicast address, 
an APN, a TMGI, a (Network Service Access Point Identity) Linked NSAPI, an IMSI 
and the like. The IP multicast address identifies an MBMS bearer service which the 
UE joined. The APN is an access point name on which this IP multicast address is 
5 defined. The TMGI is a temporary mobile group identity allocated to the MBMS 
bearer service. The Linked NSAPI is the NSAPI of the PDP context used by the UE 
to carry an IGMP/MLD signaling. The IMSI is a subscriber identity. The 
MBMS_NSAPI is a Network layer Service Access Point Identifier which identifies an 
MBMS UE Context. 
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Parameter 


Description 


UE 


SGSN 


GGSN 


RNC 


BSC 


BM- 

SC 


IP multicast 
address 


IP multicast 
address identifying 
an MBMS bearer 
that the UE has 
joined. 


X 


X 


X 


X 


Iu-X 
Gb- 
none 


X 


APN 


Access Point 
Name on which 

j. i vuiiv A X FT 111 Vil 

this IP multicast 
address is defined. 


X 


X 


X 


X 


Iu-X 
Gb - 
none 


X 


GGSN Address 
in Use 


The IP address of 
the GGSN 
currently used 




X 










SGSN address 


The IP address of 
SGSN 






x 








TMGI 


Temporary Mobile 
Group Identity 
allocated to the 
MBMS bearer 


X 


X 




X 


Iu-X 
Gb- 
none 




Linked NSAPI 


NSAPI of the PDP 
context used hv 
the UE to carry 
IGMP/MLD 
signalling. 


X 


X 










IMSI 


IMSI identifying 
the user. 


(1) 


0) 


X 


(2) 


Iu-(2) 
Gb - (3) 


X 


TI 


Transaction 
Identifier 


X 


X 










MBMS NSAPI 


Network layer 
Service Access 
Point Identifier 
which identifies 
an MBMS UE 
Context. 


x 


x 


x 


x 







Table 2 



In table 2, (1) means that in the UE and SGSN, the IMSI is available within the 
MM Context which contains the MBMS UE Context. (2) means that the IMSI is 
available within the UE Context which contains the MBMS UE Context. 

5 As shown in Figure 3, the activating method of MBMS bearer service according 

to the prior art includes the steps of: 
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Step 301: In general, when a UE needs to activate a particular MBMS bearer 
service, it will create a PDP Context (PDP Context Activation) through an interaction 
with the network. 

If the current UE has created the PDP Context with network, the created PDP 
5 Context is directly used. If the current UE has not created the PDP Context with 
network, the UE will activate a default PDP Context, the type of which is generally 
best effort. The PDP Context can be a PDP Context used in a basic IP service, such as 
WAP or Internet access, or can also be a signaling PDP Context used in an IP 
Multimedia Subsystem (IMS) access. In this embodiment, the GGSN corresponding 
1 0 to the default PDP Context is GGSNL 

Step 302: The current UE transmits an IGMP Joining or MLD Joining to GGSN1 
through the created PDP Context, wherein in the message, a particular MBMS bearer 
service which is expected to receive by the subscriber is identified by the IP multicast 
address. If IPv4 protocols are adopted, the UE transmits an IGMP Joining to GGSNL 
15 If IPv6 protocols are adopted, the UE transmits an MLD Joining to GGSNL In this 
embodiment, IPv4 protocols are adopted. 

Step 303: After receiving the IGMP/MLD Joining, GGSN1 transmits an MBMS 
Authorization Request to request the authorization for data reception of the current 
UE to a BM-SC. If the authorization request is passed, then the BM-SC transmits an 
20 MBMS Authorization Response to GGSN1, and the response carries the APN which 
is used to activate MBMS UE Context. If the authorization request is not passed, the 
MBMS Authorization Response transmitted from BM-SC to GGSN1 indicates that 
the UE cannot be authorized to receive MBMS data and the flow is ended. 

Step 304: GGSN1 transmits an MBMS Notification Request to the SGSN, 
25 wherein the request includes an IP multicast address, an APN and a Linked NSAPI. 
The configuration of the Linked NSAPI equals to a PDP Context NASPI used by 
GGSN1 when GGSN1 receives the Joining request. The IP multicast address is an IP 
multicast address in the Joining request of the UE. The APN is likely to be different 
from the APN of the activated default PDP Context, and under some circumstances, 
30 the APN possibly corresponds to another GGSN differing from GGSN1 which 
receives the IGMP/MLD Joining request. Since GGSN1 can not receive the response, 
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for example the SGSN or the UE does not support the MBMS bearer service, and 
under these circumstances, GGSN1 needs to startup an MBMS Activation Timer. 

Step 305: After receiving the MBMS Notification Request, the SGSN transmits 
an MBMS Context Activation Request to the UE, which is used to request the UE to 
5 activate an MBMS UE Context. The message at least carries an IP multicast address, 
an APN, a Linked NSAPI and a Transaction Identifier (TI). The Linked NSAPI 
allows the UE to associate the MBMS UE Context with the PDP context over which 
the UE sent the IGMP/MLD Joining in Step 302. The TI is selected by the SGSN, 
value of which is not used by other PDP Context or the MBMS UE Context activated 
10 bytheUE. 

Step 306: After creating the MBMS UE Context, the UE transmits an Activate 
MBMS Context Request to the SGSN, wherein the message includes an IP multicast 
address, an APN, an MBMS NSAPI and MBMS bearer capabilities. The IP multicast 
address is used to identify startup joined/activated MBMS bearer service The APN 
15 indicates a particular GGSN. The MBMS bearer Capabilities are used to identify the 
maximum QoS which the UE can process. The MBMS NSAPI is selected by the UE, 
value of which is not used by other PDP Context or MBMS UE Context activated by 
the UE. 

Step 307: The SGSN transmits an MBMS Notification Response to GGSN1 
20 which transmits an MBMS Notification Request in Step 304. An MBMS UE Context 
value is carried in this response and the MBMS UE Context value is used to indicate 
whether the MBMS UE Context is activated successfully. If the activation is not 
successful, the MBMS UE Context value indicates that failure of activating the 
MBMS UE Context is induced by entity of the SGSN or the UE. Once GGSN1 
25 receives unsuccessful response message or the MBMS Activation Timer is overtime, 
the GGSN1 possibly will return back to the IP multicast access specifications 
described in 3GPP 29.061. 

According to the description of IP multicast access specification described in 
3GPP 29.061, under the circumstances of no MBMS bearer service, the GGSN has 
30 functions as an IP Multicast Agent, and the Point to Point (PTP) MBMS bearer 
service can be provided in UMTS network through the functions as follows: 

8 
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a) a GGSN maintains a mobile station list including one or more multicast 
groups. When the GGSN receives an IGMP Joining or MLD Report from a mobile 
station, a list will be created/updated; 

b) based on the maintained mobile station list, multicast routing information is 
5 transmitted to Packet Switched Domain routers to perform the routing of multicast 

packets; 

c) once receiving the multicast packets, the GGSN will copy these packets and 
transmit the packets to each mobile station within the group through a PTP mode. 

It is needed to explain that the MBMS bearer service is a type of User Service, 
10 which includes two implementing forms: an MBMS bearer service and a PTP unicast 
MBMS service. 

Step 308: The SGSN implements such security functions as authentication to the 
current UE. This step can be omitted. 

Step 309: After the SGSN confirms the particular GGSN which provides the 
15 requested MBMS bearer service according to the APN in Step 306, the SGSN creates 
an MBMS UE Context and transmits a Create MBMS Context Request to this GGSN. 
The Create MBMS Context Request includes an IP multicast address, an APN and an 
MBMS_NSAPI. In this embodiment, the GGSN practically providing the requested 
MBMS bearer service is GGSN2. Of course, GGSN1 and GGSN2 can be the same 
20 GGSN. 

Step 310: GGSN2 transmits an MBMS Authorization Request to a BM-SC to 
quest the authorization for the UE, and the authorization judgment result is provided 
by an MBMS Authorization Response. 

Step 311: If GGSN2 has no MBMS Bearer Context information of the MBMS 
25 bearer service, GGSN2 transmits an MBMS Registration Request to the BM-SC, and 
the corresponding procedures are described in MBMS registration procedure 
specification. 

If the BM-SC has not assigned a TMGI for the MBMS bearer service, the BM- 
SC will assign a new TMGI which will be transferred to the GGSN and the SGSN 



9 



PCT/CN2005/000382 



EV799418077US 



through an MBMS Registration Response, further to the UE through an Activate 
MBMS Context Accept. 

The BM-SC transmits MBMS Registration Response containing the MBMS 
Bearer Context of the MBMS bearer service to GGSN2 and adds GGSN2 to the List 
5 of downstream nodes of the MBMS Bearer Context. The corresponding procedures 
are described in MBMS registration procedure specification. 

If GGSN2 has an MBMS Bearer Context of the MBMS bearer service, this step 
can be omitted. 

Step 312: GGSN2 creates an MBMS UE Context and transmits a Create MBMS 
1 0 Context Response to the SGSN. 

Step 313: If the SGSN has no MBMS Bearer Context of the MBMS bearer 
service, the SGSN will transmit an MBMS Registration Request to the GGSN, and 
the corresponding procedures are described in MBMS registration procedure 
specification. 

15 GGSN2 responds an MBMS Registration Response, which includes the 

information of the MBMS Bearer Context of the MBMS bearer service, and adds the 
identification of the SGSN to the list of downstream nodes of the MBMS Bearer 
Context. The corresponding procedures are described in MBMS registration 
procedure specification. If the SGSN has an MBMS Bearer Context of the MBMS 

20 bearer service, this step can be omitted. 

Step 314: If at least one Packet Switched Domain Radio Access bearer (PSRAB) 
is created for the UE, the SGSN provides the MBMS UE Context for the RAN. 

Step 315: the SGSN transmits an Activate MBMS Context Accept to the UE 
which includes the MBMS Bearer Capabilities which is used to identify the maximum 

25 QoS of the MBMS bearer service. The UE may consider the MBMS bearer 
capabilities when it activates more MBMS bearer service. If the SGSN verifies that 
the MBMS bearer capabilities of the UE are less than Required MBMS Bearer 
Capabilities of current requested MBMS bearer service, the SGSN rejects the Activate 
MBMS Context Request, and indicates an indicated reason to start a deactivation 

30 process for the created MBMS UE Context. 
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It can be seen from the above flow, for the UE under all the circumstances, Step 
315 must be the last step of the flow to verify whether the MBMS bearer capabilities 
of the UE are less than Required MBMS Bearer Capabilities of the current requested 
MBMS bearer service. For the UE that cannot meet the demand, since all bearers have 
5 been created for the UE through above procedures, a deactivation procedure is needed 
to be initiated to the UE. 

As a network node without storing the Required MBMS Bearer Capabilities will 
have the Required MBMS Bearer Capabilities information just after once registration, 
if the procedure for a network node judging whether MBMS bearer capabilities of 
10 other UE are less than the Required MBMS Bearer Capabilities when other UE 
implements MBMS bearer service activation still carries out according to the above 
steps when other UE accesses, the steps are so complicated that network signaling 
interactions are increased and network efficiency is reduced. 

It is mentioned in the Step 307 that the GGSN possibly returns back to the IP 
15 multicast access specifications described in 3GPP 29.061, but the IP multicast access 
specifications described in 3GPP 29.061 adopt PTP mode, which cannot save network 
resources and radio interface resources as PTM mode. Furthermore, during the above 
procedures, for the rejected UEs, no scheme of adopting other mechanisms to make 
the rejected subscribers receive requested MBMS bearer service is proposed, so the 
20 subscriber's satisfaction is greatly reduced. 

Summary of the Invention 

In view of the above, the present invention is to provide a method to implement 
MBMS activation, make the network process the request of the UE MBMS bearer 
capabilities of which are less than those demanded, thereby simplifying signaling 
25 alternation between network entities, reducing network complexity and saving 
network resources. 

In accordance with the present invention, a method for activating a Multimedia 
Broadcast/Multicast Service (MBMS) includes the steps: 
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a. sending a message which carries MBMS bearer capabilities of a user 
equipment (UE) from the UE to a SGSN which the UE belongs to after passing 
authorization; 

b. verifying whether the MBMS bearer capabilities of the UE are less than 
5 Required MBMS Bearer Capabilities, if the SGSN has the Required MBMS Bearer 

Capabilities; and 

c. rejecting a request for activating an MBMS Context if the MBMS bearer 
capabilities of the UE are less than the Required MBMS Bearer Capabilities, or 
creating an MBMS UE Context if the MBMS bearer capabilities of the UE are not 

10 less than the Required MBMS Bearer Capabilities. 

The Step a includes: 

al. creating a Packet Data Protocol (PDP) Context through interaction with a 
network and sending a joining message to the network via the SGSN which the UE 
belongs to; and 

15 a2. receiving the joining message, implementing an authorization verification to 

the UE, and permitting the UE to activate an MBMS UE Context and send the 
message which carries the MBMS bearer capabilities of the UE to the SGSN which 
the UE belongs to if the UE passes authorization; 

Rejecting the request for activating the MBMS context in the step c, further 
20 includes: 

cl 1 . sending a rejection message which carries a rejection reason to the UE; 

cl2. sending a failure message which carries a failure reason to a GGSN; and 

cl3. receiving the failure message and deciding whether to return back to an IP 
multicast access of a unicast mode. 

25 Or, rejecting the request for activating the MBMS context in the step c, further 

includes: 

c21. sending a rejection message which carries a rejection reason to the UE; and 
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c22. receiving the rejection message and reapplying to receive the MBMS bearer 
service through a unicast mode. 

Preferably, rejecting the request for activating the MBMS context in the step c, 
further includes: 

5 c3 1 . sending a failure message which carries a failure reason to a GGSN; and 

c32. receiving the failure message and deciding whether to return back to an IP 
multicast access of a unicast mode. 

Or, rejecting the request for activating the MBMS context in the step c, further 
includes: 

10 c41 . sending a failure message which carries a failure reason to a GGSN; and 

c42. receiving the failure message and deciding whether to return back to an IP 
multicast access of a unicast mode; and 

c43. sending a rejection message which carries a rejection reason to the UE. 

In the above scheme, the rejection message sent to the UE further carries the 
1 5 Required MBMS Bearer Capabilities. 

Preferably, the method further includes: 

receiving the rejection message; 

activating a timer; 

verifying whether the GGSN having returned back to the IP multicast access of 
20 the unicast mode before time-out of the timer, stopping the timer if the GGSN having 
returned back to the IP multicast access of the unicast mode before time-out of the 
timer, and reapplying to receive the MBMS bearer service through the unicast mode if 
the timer being overtime. 

Preferably, the method further includes: 
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activating a timer after the step a of sending the message which carries the 
MBMS bearer capabilities of the UE, stopping the timer if the UE receives an 
accepting message or the GGSN returns back to the IP multicast access of the unicast 
mode before time-out of the timer, and reapplying to receive the MBMS bearer 
5 service through the unicast mode if the timer being overtime. 

In the above scheme, the rejection message carries the Required MBMS Bearer 
Capabilities, the UE compares the Required MBMS Bearer Capabilities with the 
MBMS bearer capabilities of the UE after receiving the rejection message, and the UE 
reapplies to receive the MBMS bearer service through the unicast mode if the MBMS 
10 bearer capabilities of the UE are less than the Required MBMS Bearer Capabilities. 

In the above scheme, the rejection message carries the Required MBMS Bearer 
Capabilities, the UE compares the Required MBMS Bearer Capabilities with the 
MBMS bearer capabilities of the UE after receiving the rejection message, and the UE 
reapplies to receive the MBMS bearer service through the unicast mode if the MBMS 
15 bearer capabilities of the UE are less than the Required MBMS Bearer Capabilities 
and the GGSN does not return back to the IP multicast access of the a unicast mode. 

In the Step b, if the SGSN has not the Required MBMS Bearer Capabilities and 
if the MBMS bearer capabilities of the UE are less than the Required MBMS Bearer 
Capabilities, the SGSN deactivates the created MBMS UE Context, and sends a 
20 failure message to a GGSN; the GGSN receives the failure message and decides 
whether to return back to an IP multicast access of a unicast mode. 

Preferably, the method further includes: 

receiving a rejection message sent from the SGSN; 

activating a timer; 

25 verifying whether the GGSN having returned back to the IP multicast access of 

the unicast mode before time-out of the timer, stopping the timer if the GGSN having 
returned back to the EP multicast access of the unicast mode before time-out of the 
timer, and reapplying to receive the MBMS bearer service through the unicast mode if 
the timer being overtime. 
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In the above scheme, the SGSN sends the failure message to the GGSN which 
creates a PDP Context with the UE, or to the GGSN which creates an MBMS UE 
Context with the UE. 

The rejection message carries the Required MBMS Bearer Capabilities, the UE 
5 compares the Required MBMS Bearer Capabilities with the MBMS bearer 
capabilities of the UE after receiving the rejection message, and the UE reapplies to 
receive the MBMS bearer service through the unicast mode if the MBMS bearer 
capabilities of the UE are less than the Required MBMS Bearer Capabilities and the 
GGSN does not return back to the IP multicast access of the unicast mode. 

10 In the Step b, if the SGSN has no the Required MBMS Bearer Capabilities, the 

SGSN creates an MBMS UE Context; if the MBMS bearer capabilities of the UE are 
less than the Required MBMS Bearer Capabilities, the UE reapplies to receive the 
MBMS bearer service through the unicast mode after the SGSN deactivates the 
created MBMS UE Context or after the UE receives a rejection message sent from the 

15 SGSN. 

The rejection message sent from the SGSN to the UE carries the Required 
MBMS Bearer Capabilities; the UE compares the Required MBMS Bearer 
Capabilities with the MBMS bearer capabilities of the UE after receiving the rejection 
message, and the UE reapplies to receive the MBMS bearer service through the 
20 unicast mode if the MBMS bearer capabilities of the UE are less than the Required 
MBMS Bearer Capabilities. 

In the method for implementing the MBMS bearer service Activation provided 
in the present invention, when a UE activates a particular MBMS bearer service, after 
receiving the MBMS bearer capabilities of the UE during the procedure that the UE 

25 creates a PDP Context with the network, a SGSN verifies whether the MBMS bearer 
capabilities of the UE satisfy the Required MBMS Bearer Capabilities. Therefore, 
under the circumstance of the SGSN or the GGSN is unregistered, whether the 
MBMS bearer capabilities of the UE satisfy the Required MBMS Bearer Capabilities 
will be known after finishing the whole existing MBMS bearer service activation 

30 procedure while under the circumstance of the SGSN or the GGSN is registered, if the 
MBMS bearer capabilities of the UE cannot satisfy the Required MBMS Bearer 
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Capabilities, the MBMS UE Context need not be created at all. In this way, complex 
signaling interaction between the UE and the network is omitted and another 
activation operation after Activate MBMS UE Context is avoided, thereby the 
network process is simplified and the network load is reduced. 

5 In practical applications of the present invention, verifying together by the SGSN 

and the UE can be an alternative, which can ensure reliability of the verification result 
and make the activation flow of the MBMS bearer service more flexible and 
diversified. 

In addition, for the UE of which the MBMS bearer capabilities do not satisfy the 
10 Required MBMS Bearer Capabilities, the SGSN can reject directly or change the 
mode of providing service. The changing the mode of service providing is: the GGSN 
goes back to IP multicast access specifications described in 3GPP 29.061 on its 
initiative, making the UE receive the MBMS bearer service through a PTP mode; or 
the UE reapplies to receive the MBMS bearer service through a unicast mode on its 
15 initiative. In this way, the denied subscribers can receive their requested MBMS 
bearer service through other approaches. Thereby the subscriber satisfaction and the 
network utilization coefficient will be improved and the income of network operators 
will be increased; furthermore, the receiving method of MBMS bearer service 
becomes more flexible and diversified. 

20 Brief Description of the Drawings 

Figure 1 illustrates a transmission mechanism of the Multicast Service; 

Figure 2 illustrates an architecture of the radio network supporting an MBMS 
bearer service; 

Figure 3 illustrates a processing flow of MBMS bearer service activation 
25 according to conventional invention; 

Figure 4 illustrates a preferred processing flow of the method for activating an 
MBMS bearer service according to present invention; 

Figure 5 illustrates a preferred processing flow of Embodiment 1 according 
present invention; 
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Figure 6 illustrates a preferred processing flow of Embodiment 2 according 
present invention; 

Figure 7 illustrates a preferred processing flow of Embodiment 3 according 
present invention; 

5 Figure 8 illustrates a preferred processing flow of Embodiment 4 according 

present invention; 

Figure 9 illustrates a preferred processing flow of Embodiment 5 according 
present invention; 

Figure 10 illustrates a preferred processing flow of Embodiment 6 according 
1 0 present invention; 

Figure 1 1 illustrates a preferred processing flow of Embodiment 7 according 
present invention. 

Embodiments of the Invention 

According to the core idea of present invention , when a UE activates a 
15 particular MBMS bearer service, after receiving the MBMS bearer capabilities of the 
UE during the procedure that the UE creates PDP Context with the network, a SGSN 
verifies whether the MBMS bearer capabilities of the UE satisfy the demand and then 
implements corresponding process according to the verification result. In this way, the 
request of activating MBMS bearer service can be processed in advance. 

20 As shown in Figure 4, a method for activating the MBMS service according to 

the invention includes steps of: 

Step 401: A UE requesting to receive a particular MBMS bearer service first 
creates a PDP Context with network through a SGSN that the UE belongs to, and 
transmits a joining message to the network through the created PDP Context. 
25 Generally, the UE transmits the joining message to the GGSN corresponding to the 
created PDP Context. 

Steps 402-405: The network implements the authorization verification to the 
current UE transmitting the joining message. If the authorization is passed, the 
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network permits the UE to activate the MBMS UE Context, and the current UE 
transmits a message carrying its own MBMS bearer capabilities to the SGSN which it 
belongs to. If the authorization is not passed, end the current process. 

The detailed procedures of the network implementing authorization verification 
5 to the current UE is as shown in Steps 303-306 in Figure 3. After receiving the 
joining message transmitted by the current UE, the GGSN transfers an MBMS 
Authorization Request to the BM-SC to request authorization for data reception of the 
current UE. After implementing authorization verification to the current UE, the BM- 
SC returns an MBMS Authorization Response to the GGSN. If the authorization 

10 verification is passed, a special GGSN APN response message is carried in the 
MBMS Authorization Response. After receiving the MBMS Authorization Response, 
the GGSN transmits an MBMS Notification Request to the SGSN. After receiving the 
MBMS Notification Request, the SGSN requests the current UE for activating the 
MBMS UE Context. After receiving the request, the UE returns a response message 

15 carrying its own MBMS bearer capabilities. If the authorization verification is not 
passed, the MBMS Authorization Response carries an indication that the current UE 
cannot receive MBMS data, and the current process flow is ended. 

Step 406: After receiving the MBMS bearer capabilities of the UE, the SGSN 
verifies whether the Required MBMS Bearer Capabilities are stored in it. If the 
20 Required MBMS Bearer Capabilities are stored, Step 407 is implemented; otherwise, 
the conventional MBMS bearer service activation flow according to Steps 307-315 as 
shown in Figure 3 is implemented and the current process flow is ended. 

In general, there are two approaches for a SGSN to obtain the Required MBMS 
Bearer Capabilities of a particular MBMS bearer service. Obtain through Registration 

25 procedure or through network configuration set by the network operator. For the first 
circumstance that no Required MBMS Bearer Capabilities required by the MBMS 
bearer service are stored in the SGSN and GGSN only exists when the SGSN and 
GGSN registers for a first time. After the SGSN and GGSN finishes registration, the 
Required MBMS Bearer Capabilities of the MBMS bearer service will be stored in 

30 the corresponding SGSN and GGSN. 
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Steps 407-408: The SGSN verifies whether the received MBMS bearer 
capabilities of the UE are less than the Required MBMS Bearer Capabilities which are 
stored in the SGSN. If the MBMS bearer capabilities of the UE are less than the 
Required MBMS Bearer Capabilities, the SGSN rejects the Activate MBMS UE 
5 Context Request. If the MBMS bearer capabilities of the UE are not less than the 
Required MBMS Bearer Capabilities, go on with the conventional MBMS bearer 
service activating flow according to Steps 307-315 as shown in Figure 3 to finish the 
MBMS UE Context Creation. The step for verifying the MBMS bearer capabilities of 
the UE is no longer implemented in Step 315. 

10 In Step 408, after rejecting the Activate MBMS UE Context Request, the SGSN 

also can transmit an Activate MBMS UE Context Failure to the GGSN or the UE 
respectively or inform the GGSN and the UE at the same time. The GGSN or the UE 
can retransform or reapply the receiving mode of the MBMS bearer service according 
to its requirements. 

15 The Activate MBMS UE Context Failure from the SGSN to the GGSN can 

directly adopt an MBMS Notification Response according to conventional invention, 
and the activation failure indication is carried by the response message; an individual 
message also can be adopted to indicate that activating MBMS UE Context is 
unsuccessful. 

20 Embodiment 1 : 

In this embodiment, the corresponding Required MBMS Bearer Capabilities 
have been stored in the SGSN. After the SGSN receiving the MBMS bearer 
capabilities of the UE, a verification result is obtained: the MBMS bearer capabilities 
of the UE are more than or equal to the Required MBMS Bearer Capabilities. Under 
25 this circumstance, the implementing method of the MBMS bearer service activation is 
as shown in Figure 5, including steps of: 

Steps 501-506: are completely the same as all the descriptions in Steps 301-306 
according to conventional invention. 

Step 507: After receiving an Activate MBMS Context Request carrying the 
30 MBMS bearer capabilities from the UE which transmits a joining message currently, 
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the SGSN verifies whether the MBMS bearer capabilities of the UE are less than the 
Required MBMS Bearer Capabilities of the MBMS bearer service stored in it. If the 
MBMS bearer capabilities of the UE are more than or equal to the Required MBMS 
Bearer Capabilities of the MBMS bearer service, the SGSN informs the current UE 
5 that its MBMS bearer capabilities satisfy the demand. Step 508 is implemented. Of 
course, the verification result can also not be informed to the UE, and the Step 508 is 
directly implemented. 

Steps 508-51 1: are completely the same as all the descriptions in Steps 307-310 
according to conventional invention. 

10 Step 512: is completely the same as all the description in Step 312 according to 

conventional invention. 

Step 513: is completely the same as all the description in Step 314 according to 
conventional invention. 

Step 514: the SGSN transmits an Activate MBMS Context Accept to the UE, 
15 which contains the MBMS bearer capabilities which is used to identify the maximum 
QoS of the MBMS bearer service. The UE may consider the MBMS bearer 
capabilities when it activates more MBMS bearer service. 

Embodiment 2: 

In this embodiment, the corresponding Required MBMS Bearer Capabilities 
20 have been stored in the SGSN. After the SGSN receives the MBMS bearer 
capabilities of the UE, a verification result that the MBMS bearer capabilities of the 
UE are less than the Required MBMS Bearer Capabilities is obtained. After obtaining 
the verification result, the SGSN rejects the Activate MBMS Context Request and 
transmits an Activate MBMS Context Rejection to the UE at the same time, and the 
25 SGSN transmits an Activate MBMS Context Failure to the GGSN. Under these 
circumstances, the activating method of the MBMS bearer service is as shown in 
Figure 6, including steps of: 

Steps 601-606: are completely the same as all the descriptions in Steps 301-306 
according to conventional invention. 
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Step 607-608: After receiving the Activate MBMS Context Request carrying the 
MBMS bearer capabilities from the UE which transmits a joining message currently, 
the SGSN verifies whether the MBMS bearer capabilities of the UE are less than the 
Required MBMS Bearer Capabilities of the MBMS bearer service stored in it. If the 
5 MBMS bearer capabilities of the UE are less than the Required MBMS Bearer 
Capabilities of the MBMS bearer service, the SGSN rejects the current Activate 
MBMS Context Request. 

Step 609: The SGSN transmits an Activate MBMS Context Rejection to the UE, 
which indicates through an indicated reason why the MBMS UE Context could not be 
10 activated and may also carry the Required MBMS Bearer Capabilities of the 
requested MBMS bearer service. 

Step 610: The SGSN transmits an Activate MBMS Context Failure to the GGSN, 
indicating that the failure is induced by the bearer capabilities. The GGSN decides 
whether to return back to IP multicast access specifications described in 3 GPP 29.061 
1 5 according to practical situation. 

Embodiment 3: 

In this embodiment, the corresponding Required MBMS Bearer Capabilities 
have been stored in the SGSN. After the SGSN receives the MBMS bearer 
capabilities of the UE, a verification result that the MBMS bearer capabilities of the 
20 UE are less than the Required MBMS Bearer Capabilities is obtained. After obtaining 
the verification result, the SGSN only transmits an Activate MBMS Context Request 
Rejection to the UE. Under these circumstances, the activating method of the MBMS 
bearer service is as shown in Figure 7, including steps of: 

Steps 701-708: are completely the same as all the descriptions in Steps 601-608 
25 of Embodiment 2. 

Step 709: The SGSN transmits an Activate MBMS Context Rejection to the UE, 
which indicates through an indicated reason why the MBMS UE Context could not be 
activated and may also carry the Required MBMS Bearer Capabilities of the 
requested MBMS bearer service. 
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Step 710: After receiving the Activate MBMS Context Rejection, the UE 
reapplies to carry out IP multicast access specifications described in 3GPP 29.061, 
adopting unicast mode, i.e., PTP mode to receive the requested MBMS bearer service. 

With respect to this embodiment, if the Activate MBMS Context Rejection 
5 which is transmitted from the SGSN to the UE in Step 709 carries the Required 
MBMS Bearer Capabilities of the requested MBMS bearer service. Then the UE also 
can compare the Required MBMS Bearer Capabilities with its own MBMS bearer 
capabilities once more after receiving the Activate MBMS Context Rejection. After 
obtaining a verification result that its own MBMS bearer capabilities are less than the 
10 Required MBMS Bearer Capabilities, the UE reapplies to receive the requested 
MBMS bearer service through unicast mode which is described in 3 GPP 29.061 . 

Embodiment 4: 

In this embodiment, the corresponding Required MBMS Bearer Capabilities 
have been stored in the SGSN. After the SGSN receives the MBMS bearer 

15 capabilities of the UE, a verification result that the MBMS bearer capabilities of the 
UE are less than the Required MBMS Bearer Capabilities is obtained. After obtaining 
the verification result, the SGSN rejects MBMS Context Request, and then transmits 
an Activate MBMS Context Failure to the GGSN. Under this circumstance, the 
implementing method of the MBMS bearer service activation is as shown in Figure 8, 

20 including steps of: 

Steps 801-808: are completely the same as all the descriptions in Steps 601-608 
of Embodiment 2. 

Step 809: The SGSN transmits an Activate MBMS Context Failure to the GGSN, 
indicating that the failure is induced by the bearer capabilities. The GGSN decides 
25 whether to go back to IP multicast access specifications described in 3GPP 29.061 
according to practical situation. 

Embodiment 5: 

In this embodiment, the corresponding Required MBMS Bearer Capabilities 
information has been stored in the SGSN. After the SGSN receives the MBMS bearer 
30 capabilities of the UE, a verification result that the MBMS bearer capabilities of the 
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UE are less than the Required MBMS Bearer Capabilities is obtained After obtaining 
the verification result, the SGSN rejects the Activate MBMS Context Request, 
transmits an Activate MBMS Context Failure to the GGSN, and then transmits an 
Activate MBMS Context Rejection to the UE. Under this circumstance, the activating 
5 method of the MBMS bearer service is as shown in Figure 9, including steps of: 

Steps 901-908: are completely the same as all the descriptions in Steps 601-608 
of Embodiment 2. 

Step 909: The SGSN transmits an Activate MBMS Context Failure to the GGSN, 
indicating that the failure is induced by the bearer capabilities. The GGSN decides 
10 whether to return back to IP multicast access specifications described in 3 GPP 29.061 
according to practical situation. 

Step 910: The SGSN transmits an Activate MBMS Context Rejection to the UE, 
which indicates through an indicated reason why the MBMS UE Context could not be 
activated and may also carry the Required MBMS Bearer Capabilities of the 
1 5 requested MBMS bearer service. 

In above five embodiments, for embodiment 2 and embodiment 5, the last step is 
that the SGSN transmits an Activate MBMS Context Failure to the GGSN, and the 
GGSN possibly goes back to IP multicast access specifications described in 3GPP 
29.061. For the circumstances that the GGSN does not return back, after the UE 

20 receiving Activate MBMS Context Rejection message transmitted from the SGSN, 
the UE also can activate a Timer, start timing and verify whether the GGSN to return 
back at the same time. If the GGSN returns back before time-out of the Timer, the 
Timer is stopped; if the Timer is overtime, the UE reapplies to carry out IP multicast 
access specifications described in 3GPP 29.061, adopting unicast mode, i.e., PTP 

25 mode to receive the requested MBMS bearer service. 

For Embodiment 4, after transmitting Activate MBMS Context Request to the 
SGSN, the UE activates a Timer and starts timing. If the UE receives the Activate 
MBMS Context Accept or the GGSN returns back to IP multicast access before time- 
out of the Timer, the Timer is stopped. If the UE does not receive the Activate MBMS 
30 Context Accept and the GGSN does not return back to IP multicast access before 
time-out of the Timer, the UE reapplies to carry out IP multicast access specifications 

23 



PCT/CN2005/000382 



EV799418077US 



described in 3GPP 29.061, adopting unicast mode, i.e., PTP mode to receive the 
requested MBMS bearer service. 

For Embodiment 2 and Embodiment 5, if the Activate MBMS Context Rejection 
which is transmitted from the SGSN to the UE carries the Required MBMS Bearer 
5 Capabilities of the requested MBMS bearer service. Then UE also can compare the 
Required MBMS Bearer Capabilities with its own MBMS bearer capabilities once 
again after receiving the Activate MBMS Context Rejection; after obtaining a 
verification result that its own MBMS bearer capabilities are less than the Required 
MBMS Bearer Capabilities, if the GGSN does not return back to IP multicast access, 
10 the UE reapplies to receive the requested MBMS bearer service through a unicast 
mode. 

Embodiment 6: 

In this embodiment, the corresponding MBMS bearer capabilities have not been 
stored in the SGSN, and the MBMS UE Context is activated successfully, then the 

15 procedures follow the conventional invention. Furthermore, for the circumstance that 
the MBMS bearer capabilities of the UE are less than the Required MBMS Bearer 
Capabilities, the SGSN not only deactivates the created MBMS UE Context, but also 
transmits an Activate MBMS Context Failure to the GGSN. And then the GGSN 
decides whether to return back to IP multicast access specifications described in 3 GPP 

20 29.061 according to practical situation. Under this circumstance, the activating 
method of the MBMS bearer service is as shown in Figure 10, including steps of: 

Steps 1001-1006: are completely the same as all the descriptions in Steps 
301-306 according to conventional invention. 

Steps 1007-1008: the SGSN detects the corresponding Required MBMS Bearer 
25 Capabilities are not stored in it. After receiving the Activate MBMS Context Request 
which carries the MBMS bearer capabilities of the UE and is transmitted from the UE 
that is currently transmitting a joining message. In such circumstance, the SGSN has 
not registered and cannot verify whether the MBMS bearer capabilities of the UE 
satisfy the demand. So the SGSN directly returns an MBMS Notification Response to 
30 GGSN1 which transmits MBMS Notification Request. The response carries an 
indicated reason, and the MBMS UE Context is used to indicate whether the MBMS 
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UE Context is activated successfully and if it is failure, the MBMS UE Context 
further indicates the failure is induced by the SGSN or the UE. In this embodiment, 
the response indicates that the MBMS UE Context has been activated successfully. 

Steps 1009-1015 are basically as same as all the descriptions in Steps 308-314 
5 according to conventional invention, and, Step 1012 and Step 1014 cannot be omitted. 

Step 1016: The SGSN verifies whether the MBMS bearer capabilities of the UE 
are less than the Required MBMS Bearer Capabilities of the requested MBMS bearer 
service according to its stored MBMS bearer capabilities. If the MBMS bear 
capabilities are not less than the Required MBMS Bearer Capabilities, the SGSN 
10 transmits an Activate MBMS Context Accept carrying the MBMS bearer capabilities 
to the UE, and the current process flow is ended. In this step, the MBMS bearer 
capabilities are used to identify the maximum QoS of the MBMS bearer service. The 
UE is likely to consider the MBMS bearer capabilities when it activates more MBMS 
bearer services. 

15 If the MBMS bearer capabilities of the UE are less than the Required MBMS 

Bearer Capabilities of the current MBMS bearer service, the SGSN rejects the 
Activate MBMS UE Context Request, and transmits an Activate MBMS Context 
Reject message which indicates an indicated reason and deactivates the created 
MBMS UE Context, and then implements Step 1017. In this embodiment, the MBMS 

20 bearer capabilities of the UE are less than the Required MBMS Bearer Capabilities of 
the current MBMS bearer service. 

Step 1017: After deactivating the MBMS UE Context, the SGSN transmits an 
Activate MBMS Context Failure to GGSN1 or GGSN2, indicating that the failure is 
induced by the MBMS bearer capabilities. GGSN1 or GGSN2 decides whether to 
25 return back to IP multicast access specifications described in 3GPP 29.061 according 
to practical situation. 

In this embodiment, with respect to the circumstances that the GGSN does not 
return back, after receiving the Activate MBMS Context Rejection transmitted from 
the SGSN in Step 1016, the UE activate a Timer, start timing and verify whether the 
30 GGSN to returns back at the same time. If the GGSN returns back before time-out of 
the Timer, the Timer is stopped. If the Timer is overtime, the UE reapplies to carry 
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out IP multicast access specifications described in 3GPP 29.061, adopting unicast 
mode, i.e., PTP mode to receive the requested MBMS bearer service. 

In this embodiment, if the Activate MBMS Context Rejection which is 
transmitted from the SGSN to the UE carries the Required MBMS Bearer Capabilities 
5 of the requested MBMS bearer service in Step 1016. Then the UE can also compare 
the Required MBMS Bearer Capabilities with its own MBMS bearer capabilities once 
again after receiving the Activate MBMS Context Rejection. After obtaining a 
verification result that its own MBMS bearer capabilities are less than the Required 
MBMS Bearer Capabilities, if it is detected that the GGSN does not returns back to IP 
10 multicast access, the UE reapplies to receive the requested MBMS bearer service 
through a unicast mode. 

Embodiment 7: 

In this embodiment, the corresponding Required MBMS Bearer Capabilities are 
not stored in the SGSN, but the MBMS UE Context is activated successfully. The 

15 procedures follow the conventional invention, and the MBMS bearer capabilities of 
the UE are verified in the last step. Furthermore, for the circumstance that the MBMS 
bearer capabilities of the UE are less than the Required MBMS Bearer Capabilities, 
the SGSN not only deactivates the created MBMS UE Context, but also reapplies to 
receive the current MBMS bearer service through a unicast mode when it receives an 

20 Activate MBMS Context Rejection. Under this circumstance, the activating method of 
the MBMS bearer service is as shown in Figure 1 1 , including steps of: 

Steps 1101-1116: are completely the same as all the descriptions in Steps 
1001-1016 of Embodiment 6. 

Step 1117: After receiving the Activate MBMS Context Rejection or 
25 deactivating the MBMS UE Context, the UE reapplies to carry out IP multicast access 
specifications described in 3GPP 29.061, adopting unicast mode, i.e., PTP mode to 
receive the requested MBMS bearer service. 

In this embodiment, if the Activate MBMS Context Rejection transmitted from 
the SGSN to the UE carries the Required MBMS Bearer Capabilities of the requested 
30 MBMS bearer service in Step 1116. The UE also can compare the Required MBMS 
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Bearer Capabilities with its own MBMS bearer capabilities once again after receiving 
the Activate MBMS Context Rejection. After obtaining a verification result that its 
own MBMS bearer capabilities are less than the Required MBMS Bearer Capabilities, 
if the GGSN does not return back to the IP multicast access, the UE reapplies to 
5 receive the requested MBMS bearer service through a unicast mode. 

Of course, for the circumstances of embodiment 6 and embodiment 7, the 
activating flow of the MBMS bearer service can also be ended after deactivation 
procedures, omitting Step 1017 or Step 1117. 

The specification and drawings are, accordingly, to be regarded in an illustrative 
10 rather than a restrictive sense. It will, however, be evident that additions, subtractions, 
substitutions, and other modifications may be made without departing from the 
broader spirit and scope of the invention as set forth in the claims. 
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